There are many scenarios where, the use of device credentials alone is not sufficient; a human user is required to provide consent to allow the system to create anti-repudiation mechanisms to track or authenticate customers.
The most straightforward solution for an operator, for example, a service provider switch, is that a user would register with “new” operator using a PC and performing a subscriber authentication through a secure HTTP web interface (using SSL or TLS) and then do the same with the “old” operator. The issue is that this process is not only time consuming and cumbersome, but also does not provide any proof for archiving for future use, by itself, and if the two operators don't trust each other, they won't trust each other's authentication. Further, without device-subscriber binding, it is not clear if the subscriber uses the same device identifier for both of the processes. So a malicious subscriber could provide consent to switch device 1 while interacting with “new” operator, while providing a device 2 identifier when interacting with “old” operator and this way cause a denial of service for device 2 (that could belong to another user). Further, weaker devices may not be able to handle TLS or SSL stacks or other processor-heavy requirement.
There are authentication protocols such as PEAP, EAP-FAST that provide separate user and device authentication profile but they don't provide any evidence that can be passed to third parties.
SAML is a process used for providing assertion of user authentication, but SAML is not issued for a large population of devices. Further, the small M2M devices may lack the capability to support SAML tokens.
Kerberos is another 3 party authentication/authorization mechanism. However, in Kerberos typically the authentication server is a trusted third party that provides the source of trust behind issuing service tickets. Thus neither can act as a source of trust. Kerberos may be used to solve the user consent problem in operator switch. In such a scenario, the subscription manager would need to act as the Kerberos authentication server. The subscription manager must perform prior authentication of subscriber and issuance of a ticket granting ticket first. When subscriber needs to interact with each of the operator, it then has to go to the authentication server and to the ticket granting server and ask for specific tickets for use with each operator. Those tickets are typically encrypted using a symmetric key shared between Kerberos ticket granting server and other servers. This not only means several rounds of interactions, but also requires that symmetric keys be established between the ticket granting server (subscription manger) and those servers (operator) and thus complicates the solution.
Essentially the problem is that in order for an operator change to happen, three parties need to be in agreement: the subscriber, the “old” operator and the “new” operator. Both the “new” and “old” operator need to make sure that the user has provided consent to the move, potentially without trusting each other. Thus, authentication of a user by one of the “old” or “new” operators may not provide enough evidence to satisfy the other operator that the user has provided consent. Thus, both operators must independently ascertain that the user has provided consent. The subscriber credential used in the process may be a password or a PIN or anything that is accessible to a human user. For simplicity we use the term subscriber password (SPW) going forward.